<!DOCTYPE html>

<html>
  <head>
    <meta charset="utf-8">
    
    <title>Releasing a Version &mdash; NumPy v1.18 Manual</title>
    
    <link rel="stylesheet" type="text/css" href="../_static/css/spc-bootstrap.css">
    <link rel="stylesheet" type="text/css" href="../_static/css/spc-extend.css">
    <link rel="stylesheet" href="../_static/scipy.css" type="text/css" >
    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" >
    <link rel="stylesheet" href="../_static/graphviz.css" type="text/css" >
    
    <script type="text/javascript">
      var DOCUMENTATION_OPTIONS = {
        URL_ROOT:    '../',
        VERSION:     '1.18.1',
        COLLAPSE_INDEX: false,
        FILE_SUFFIX: '.html',
        HAS_SOURCE:  false
      };
    </script>
    <script type="text/javascript" src="../_static/jquery.js"></script>
    <script type="text/javascript" src="../_static/underscore.js"></script>
    <script type="text/javascript" src="../_static/doctools.js"></script>
    <script type="text/javascript" src="../_static/language_data.js"></script>
    <script type="text/javascript" src="../_static/js/copybutton.js"></script>
    <link rel="author" title="About these documents" href="../about.html" >
    <link rel="index" title="Index" href="../genindex.html" >
    <link rel="search" title="Search" href="../search.html" >
    <link rel="top" title="NumPy v1.18 Manual" href="../index.html" >
    <link rel="up" title="Contributing to NumPy" href="index.html" >
    <link rel="next" title="NumPy governance" href="governance/index.html" >
    <link rel="prev" title="NumPy C Style Guide" href="style_guide.html" > 
  </head>
  <body>
<div class="container">
  <div class="top-scipy-org-logo-header" style="background-color: #a2bae8;">
    <a href="../index.html">
      <img border=0 alt="NumPy" src="../_static/numpy_logo.png"></a>
    </div>
  </div>
</div>


    <div class="container">
      <div class="main">
        
	<div class="row-fluid">
	  <div class="span12">
	    <div class="spc-navbar">
              
    <ul class="nav nav-pills pull-left">
        <li class="active"><a href="https://numpy.org/">NumPy.org</a></li>
        <li class="active"><a href="https://numpy.org/doc">Docs</a></li>
        
        <li class="active"><a href="../index.html">NumPy v1.18 Manual</a></li>
        

          <li class="active"><a href="index.html" accesskey="U">Contributing to NumPy</a></li> 
    </ul>
              
              
    <ul class="nav nav-pills pull-right">
      <li class="active">
        <a href="../genindex.html" title="General Index"
           accesskey="I">index</a>
      </li>
      <li class="active">
        <a href="governance/index.html" title="NumPy governance"
           accesskey="N">next</a>
      </li>
      <li class="active">
        <a href="style_guide.html" title="NumPy C Style Guide"
           accesskey="P">previous</a>
      </li>
    </ul>
              
	    </div>
	  </div>
	</div>
        

	<div class="row-fluid">
      <div class="spc-rightsidebar span3">
        <div class="sphinxsidebarwrapper">
  <h3><a href="../contents.html">Table of Contents</a></h3>
  <ul>
<li><a class="reference internal" href="#">Releasing a Version</a><ul>
<li><a class="reference internal" href="#how-to-prepare-a-release">How to Prepare a Release</a><ul>
<li><a class="reference internal" href="#current-build-and-release-info">Current build and release info</a><ul>
<li><a class="reference internal" href="#source-tree">Source tree</a></li>
<li><a class="reference internal" href="#numpy-docs">NumPy Docs</a></li>
<li><a class="reference internal" href="#scipy-org-wiki">SciPy.org wiki</a></li>
<li><a class="reference internal" href="#doc-wiki">Doc wiki</a></li>
<li><a class="reference internal" href="#release-scripts">Release Scripts</a></li>
</ul>
</li>
<li><a class="reference internal" href="#supported-platforms-and-versions">Supported platforms and versions</a><ul>
<li><a class="reference internal" href="#os-x">OS X</a></li>
<li><a class="reference internal" href="#windows">Windows</a></li>
<li><a class="reference internal" href="#linux">Linux</a></li>
<li><a class="reference internal" href="#bsd-solaris">BSD / Solaris</a></li>
</ul>
</li>
<li><a class="reference internal" href="#tool-chain">Tool chain</a><ul>
<li><a class="reference internal" href="#compilers">Compilers</a></li>
<li><a class="reference internal" href="#building-source-archives-and-wheels">Building source archives and wheels</a></li>
<li><a class="reference internal" href="#building-docs">Building docs</a></li>
<li><a class="reference internal" href="#uploading-to-pypi">Uploading to PyPI</a></li>
<li><a class="reference internal" href="#generating-author-pr-lists">Generating author/pr lists</a></li>
<li><a class="reference internal" href="#virtualenv">Virtualenv</a></li>
</ul>
</li>
<li><a class="reference internal" href="#what-is-released">What is released</a><ul>
<li><a class="reference internal" href="#wheels">Wheels</a></li>
<li><a class="reference internal" href="#other">Other</a></li>
<li><a class="reference internal" href="#source-distribution">Source distribution</a></li>
</ul>
</li>
<li><a class="reference internal" href="#release-process">Release process</a><ul>
<li><a class="reference internal" href="#agree-on-a-release-schedule">Agree on a release schedule</a></li>
<li><a class="reference internal" href="#make-sure-current-branch-builds-a-package-correctly">Make sure current branch builds a package correctly</a></li>
<li><a class="reference internal" href="#check-deprecations">Check deprecations</a></li>
<li><a class="reference internal" href="#check-the-c-api-version-number">Check the C API version number</a></li>
<li><a class="reference internal" href="#check-the-release-notes">Check the release notes</a></li>
<li><a class="reference internal" href="#update-the-release-status-and-create-a-release-tag">Update the release status and create a release “tag”</a></li>
<li><a class="reference internal" href="#apply-patch-to-fix-bogus-strides">Apply patch to fix bogus strides</a></li>
<li><a class="reference internal" href="#update-the-version-of-the-master-branch">Update the version of the master branch</a></li>
<li><a class="reference internal" href="#trigger-the-wheel-builds-on-travis-ci-and-appveyor">Trigger the wheel builds on travis-ci and Appveyor</a></li>
<li><a class="reference internal" href="#make-the-release">Make the release</a></li>
<li><a class="reference internal" href="#build-and-archive-documentation">Build and archive documentation</a></li>
<li><a class="reference internal" href="#update-pypi">Update PyPI</a></li>
<li><a class="reference internal" href="#push-the-release-tag-and-commit">Push the release tag and commit</a></li>
<li><a class="reference internal" href="#update-scipy-org">Update scipy.org</a></li>
<li><a class="reference internal" href="#announce-to-the-lists">Announce to the lists</a></li>
<li><a class="reference internal" href="#announce-to-linux-weekly-news">Announce to Linux Weekly News</a></li>
<li><a class="reference internal" href="#after-the-final-release">After the final release</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#step-by-step-directions">Step-by-Step Directions</a><ul>
<li><a class="reference internal" href="#release-walkthrough">Release  Walkthrough</a><ul>
<li><a class="reference internal" href="#backport-pull-requests">Backport Pull Requests</a></li>
<li><a class="reference internal" href="#update-release-documentation">Update Release documentation</a></li>
<li><a class="reference internal" href="#finish-the-release-note">Finish the Release Note</a></li>
<li><a class="reference internal" href="#prepare-the-release-commit">Prepare the release commit</a></li>
<li><a class="reference internal" href="#build-source-releases">Build source releases</a></li>
<li><a class="reference internal" href="#build-wheels">Build wheels</a></li>
<li><a class="reference internal" href="#download-wheels">Download wheels</a></li>
<li><a class="reference internal" href="#generate-the-readme-files">Generate the README files</a></li>
<li><a class="reference internal" href="#tag-the-release">Tag the release</a></li>
<li><a class="reference internal" href="#reset-the-maintenance-branch-into-a-development-state">Reset the maintenance branch into a development state</a></li>
<li><a class="reference internal" href="#upload-to-pypi">Upload to PyPI</a></li>
<li><a class="reference internal" href="#upload-files-to-github">Upload files to github</a></li>
<li><a class="reference internal" href="#upload-documents-to-numpy-org">Upload documents to numpy.org</a></li>
<li><a class="reference internal" href="#announce-the-release-on-scipy-org">Announce the release on scipy.org</a></li>
<li><a class="reference internal" href="#announce-to-mailing-lists">Announce to mailing lists</a></li>
<li><a class="reference internal" href="#post-release-tasks">Post-Release Tasks</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>

  <h4>Previous topic</h4>
  <p class="topless"><a href="style_guide.html"
                        title="previous chapter">NumPy C Style Guide</a></p>
  <h4>Next topic</h4>
  <p class="topless"><a href="governance/index.html"
                        title="next chapter">NumPy governance</a></p>
<div id="searchbox" style="display: none" role="search">
  <h4>Quick search</h4>
    <div>
    <form class="search" action="../search.html" method="get">
      <input type="text" style="width: inherit;" name="q" />
      <input type="submit" value="search" />
      <input type="hidden" name="check_keywords" value="yes" />
      <input type="hidden" name="area" value="default" />
    </form>
    </div>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
        </div>
      </div>
          <div class="span9">
            
        <div class="bodywrapper">
          <div class="body" id="spc-section-body">
            
  <div class="section" id="releasing-a-version">
<h1>Releasing a Version<a class="headerlink" href="#releasing-a-version" title="Permalink to this headline">¶</a></h1>
<div class="section" id="how-to-prepare-a-release">
<h2>How to Prepare a Release<a class="headerlink" href="#how-to-prepare-a-release" title="Permalink to this headline">¶</a></h2>
<p>This file gives an overview of what is necessary to build binary releases for
NumPy.</p>
<div class="section" id="current-build-and-release-info">
<h3>Current build and release info<a class="headerlink" href="#current-build-and-release-info" title="Permalink to this headline">¶</a></h3>
<p>The current info on building and releasing NumPy and SciPy is scattered in
several places. It should be summarized in one place, updated, and where
necessary described in more detail. The sections below list all places where
useful info can be found.</p>
<div class="section" id="source-tree">
<h4>Source tree<a class="headerlink" href="#source-tree" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><p>INSTALL.rst.txt</p></li>
<li><p>release.sh</p></li>
<li><p>pavement.py</p></li>
</ul>
</div>
<div class="section" id="numpy-docs">
<h4>NumPy Docs<a class="headerlink" href="#numpy-docs" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><p><a class="reference external" href="https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt">https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt</a></p></li>
<li><p><a class="reference external" href="http://projects.scipy.org/numpy/wiki/MicrosoftToolchainSupport">http://projects.scipy.org/numpy/wiki/MicrosoftToolchainSupport</a> (dead link)</p></li>
</ul>
</div>
<div class="section" id="scipy-org-wiki">
<h4>SciPy.org wiki<a class="headerlink" href="#scipy-org-wiki" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><p><a class="reference external" href="https://www.scipy.org/Installing_SciPy">https://www.scipy.org/Installing_SciPy</a> and links on that page.</p></li>
<li><p><a class="reference external" href="http://new.scipy.org/building/windows.html">http://new.scipy.org/building/windows.html</a> (dead link)</p></li>
</ul>
</div>
<div class="section" id="doc-wiki">
<h4>Doc wiki<a class="headerlink" href="#doc-wiki" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><p><a class="reference external" href="http://docs.scipy.org/numpy/docs/numpy-docs/user/install.rst/">http://docs.scipy.org/numpy/docs/numpy-docs/user/install.rst/</a> (dead link)</p></li>
</ul>
</div>
<div class="section" id="release-scripts">
<h4>Release Scripts<a class="headerlink" href="#release-scripts" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><p><a class="reference external" href="https://github.com/numpy/numpy-vendor">https://github.com/numpy/numpy-vendor</a></p></li>
</ul>
</div>
</div>
<div class="section" id="supported-platforms-and-versions">
<h3>Supported platforms and versions<a class="headerlink" href="#supported-platforms-and-versions" title="Permalink to this headline">¶</a></h3>
<p>Python 2.7 and &gt;=3.4 are the currently supported versions when building from
source.  We test NumPy against all these versions every time we merge code to
master.  Binary installers may be available for a subset of these versions (see
below).</p>
<div class="section" id="os-x">
<h4>OS X<a class="headerlink" href="#os-x" title="Permalink to this headline">¶</a></h4>
<p>Python 2.7 and &gt;=3.4 are the versions for which we provide binary installers.
OS X versions &gt;= 10.6 are supported.  We build binary wheels for OSX that are
compatible with Python.org Python, system Python, homebrew and macports - see
this <a class="reference external" href="https://github.com/MacPython/wiki/wiki/Spinning-wheels">OSX wheel building summary</a> for details.</p>
</div>
<div class="section" id="windows">
<h4>Windows<a class="headerlink" href="#windows" title="Permalink to this headline">¶</a></h4>
<p>We build 32- and 64-bit wheels for Python 2.7, 3.4, 3.5 on Windows. Windows
XP, Vista, 7, 8 and 10 are supported.  We build NumPy using the MSVC compilers
on Appveyor, but we are hoping to update to a <a class="reference external" href="https://mingwpy.github.io">mingw-w64 toolchain</a>.  The Windows wheels use ATLAS for BLAS / LAPACK.</p>
</div>
<div class="section" id="linux">
<h4>Linux<a class="headerlink" href="#linux" title="Permalink to this headline">¶</a></h4>
<p>We build and ship <a class="reference external" href="https://www.python.org/dev/peps/pep-0513">manylinux1</a>
wheels for NumPy.  Many Linux distributions include their own binary builds
of NumPy.</p>
</div>
<div class="section" id="bsd-solaris">
<h4>BSD / Solaris<a class="headerlink" href="#bsd-solaris" title="Permalink to this headline">¶</a></h4>
<p>No binaries are provided, but successful builds on Solaris and BSD have been
reported.</p>
</div>
</div>
<div class="section" id="tool-chain">
<h3>Tool chain<a class="headerlink" href="#tool-chain" title="Permalink to this headline">¶</a></h3>
<p>We build all our wheels on cloud infrastructure - so this list of compilers is
for information and debugging builds locally.  See the <code class="docutils literal notranslate"><span class="pre">.travis.yml</span></code> and
<code class="docutils literal notranslate"><span class="pre">appveyor.yml</span></code> scripts in the <a class="reference external" href="https://github.com/MacPython/numpy-wheels">numpy wheels</a> repo for the definitive source
of the build recipes. Packages that are available using pip are noted.</p>
<div class="section" id="compilers">
<h4>Compilers<a class="headerlink" href="#compilers" title="Permalink to this headline">¶</a></h4>
<p>The same gcc version is used as the one with which Python itself is built on
each platform. At the moment this means:</p>
<ul class="simple">
<li><p>OS X builds on travis currently use <em class="xref py py-obj">clang</em>.  It appears that binary wheels
for OSX &gt;= 10.6 can be safely built from the travis-ci OSX 10.9 VMs
when building against the Python from the Python.org installers;</p></li>
<li><p>Windows builds use the MSVC version corresponding to the Python being built
against;</p></li>
<li><p>Manylinux1 wheels use the gcc provided on the Manylinux docker images.</p></li>
</ul>
<p>You will need Cython for building the binaries.  Cython compiles the <code class="docutils literal notranslate"><span class="pre">.pyx</span></code>
files in the NumPy distribution to <code class="docutils literal notranslate"><span class="pre">.c</span></code> files.</p>
</div>
<div class="section" id="building-source-archives-and-wheels">
<h4>Building source archives and wheels<a class="headerlink" href="#building-source-archives-and-wheels" title="Permalink to this headline">¶</a></h4>
<p>You will need write permission for numpy-wheels in order to trigger wheel
builds.</p>
<ul class="simple">
<li><p>Python(s) from <a class="reference external" href="https://python.org">python.org</a> or linux distro.</p></li>
<li><p>cython (pip)</p></li>
<li><p>virtualenv (pip)</p></li>
<li><p>Paver (pip)</p></li>
<li><p>pandoc <a class="reference external" href="https://www.pandoc.org">pandoc.org</a> or linux distro.</p></li>
<li><p>numpy-wheels <a class="reference external" href="https://github.com/MacPython/numpy-wheels">https://github.com/MacPython/numpy-wheels</a> (clone)</p></li>
</ul>
</div>
<div class="section" id="building-docs">
<h4>Building docs<a class="headerlink" href="#building-docs" title="Permalink to this headline">¶</a></h4>
<p>Building the documents requires a number of latex <code class="docutils literal notranslate"><span class="pre">.sty</span></code> files. Install them
all to avoid aggravation.</p>
<ul class="simple">
<li><p>Sphinx (pip)</p></li>
<li><p>numpydoc (pip)</p></li>
<li><p>Matplotlib</p></li>
<li><p>Texlive (or MikTeX on Windows)</p></li>
</ul>
</div>
<div class="section" id="uploading-to-pypi">
<h4>Uploading to PyPI<a class="headerlink" href="#uploading-to-pypi" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><p>terryfy <a class="reference external" href="https://github.com/MacPython/terryfy">https://github.com/MacPython/terryfy</a> (clone).</p></li>
<li><p>beautifulsoup4 (pip)</p></li>
<li><p>delocate (pip)</p></li>
<li><p>auditwheel (pip)</p></li>
<li><p>twine (pip)</p></li>
</ul>
</div>
<div class="section" id="generating-author-pr-lists">
<h4>Generating author/pr lists<a class="headerlink" href="#generating-author-pr-lists" title="Permalink to this headline">¶</a></h4>
<p>You will need a personal access token
<a class="reference external" href="https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/">https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/</a>
so that scripts can access the github NumPy repository.</p>
<ul class="simple">
<li><p>gitpython (pip)</p></li>
<li><p>pygithub (pip)</p></li>
</ul>
</div>
<div class="section" id="virtualenv">
<h4>Virtualenv<a class="headerlink" href="#virtualenv" title="Permalink to this headline">¶</a></h4>
<p>Virtualenv is a very useful tool to keep several versions of packages around.
It is also used in the Paver script to build the docs.</p>
</div>
</div>
<div class="section" id="what-is-released">
<h3>What is released<a class="headerlink" href="#what-is-released" title="Permalink to this headline">¶</a></h3>
<div class="section" id="wheels">
<h4>Wheels<a class="headerlink" href="#wheels" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><p>Windows wheels for Python 2.7, 3.4, 3.5, for 32- and 64-bit, built using
Appveyor;</p></li>
<li><p>Dual architecture OSX wheels built via travis-ci;</p></li>
<li><p>32- and 64-bit Manylinux1 wheels built via travis-ci.</p></li>
</ul>
<p>See the <a class="reference external" href="https://github.com/MacPython/numpy-wheels">numpy wheels</a> building repository for more detail.</p>
</div>
<div class="section" id="other">
<h4>Other<a class="headerlink" href="#other" title="Permalink to this headline">¶</a></h4>
<ul class="simple">
<li><p>Release Notes</p></li>
<li><p>Changelog</p></li>
</ul>
</div>
<div class="section" id="source-distribution">
<h4>Source distribution<a class="headerlink" href="#source-distribution" title="Permalink to this headline">¶</a></h4>
<p>We build source releases in both .zip and .tar.gz formats.</p>
</div>
</div>
<div class="section" id="release-process">
<h3>Release process<a class="headerlink" href="#release-process" title="Permalink to this headline">¶</a></h3>
<div class="section" id="agree-on-a-release-schedule">
<h4>Agree on a release schedule<a class="headerlink" href="#agree-on-a-release-schedule" title="Permalink to this headline">¶</a></h4>
<p>A typical release schedule is one beta, two release candidates and a final
release.  It’s best to discuss the timing on the mailing list first, in order
for people to get their commits in on time, get doc wiki edits merged, etc.
After a date is set, create a new maintenance/x.y.z branch, add new empty
release notes for the next version in the master branch and update the Trac
Milestones.</p>
</div>
<div class="section" id="make-sure-current-branch-builds-a-package-correctly">
<h4>Make sure current branch builds a package correctly<a class="headerlink" href="#make-sure-current-branch-builds-a-package-correctly" title="Permalink to this headline">¶</a></h4>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">clean</span> <span class="o">-</span><span class="n">fxd</span>
<span class="n">python</span> <span class="n">setup</span><span class="o">.</span><span class="n">py</span> <span class="n">bdist</span>
<span class="n">python</span> <span class="n">setup</span><span class="o">.</span><span class="n">py</span> <span class="n">sdist</span>
</pre></div>
</div>
<p>To actually build the binaries after everything is set up correctly, the
release.sh script can be used. For details of the build process itself, it is
best to read the pavement.py script.</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>The following steps are repeated for the beta(s), release
candidates(s) and the final release.</p>
</div>
</div>
<div class="section" id="check-deprecations">
<h4>Check deprecations<a class="headerlink" href="#check-deprecations" title="Permalink to this headline">¶</a></h4>
<p>Before the release branch is made, it should be checked that all deprecated
code that should be removed is actually removed, and all new deprecations say
in the docstring or deprecation warning at what version the code will be
removed.</p>
</div>
<div class="section" id="check-the-c-api-version-number">
<h4>Check the C API version number<a class="headerlink" href="#check-the-c-api-version-number" title="Permalink to this headline">¶</a></h4>
<p>The C API version needs to be tracked in three places</p>
<ul class="simple">
<li><p>numpy/core/setup_common.py</p></li>
<li><p>numpy/core/code_generators/cversions.txt</p></li>
<li><p>numpy/core/include/numpy/numpyconfig.h</p></li>
</ul>
<p>There are three steps to the process.</p>
<ol class="arabic">
<li><p>If the API has changed, increment the C_API_VERSION in setup_common.py. The
API is unchanged only if any code compiled against the current API will be
backward compatible with the last released NumPy version. Any changes to
C structures or additions to the public interface will make the new API
not backward compatible.</p></li>
<li><p>If the C_API_VERSION in the first step has changed, or if the hash of
the API has changed, the cversions.txt file needs to be updated. To check
the hash, run the script numpy/core/cversions.py and note the API hash that
is printed. If that hash does not match the last hash in
numpy/core/code_generators/cversions.txt the hash has changed. Using both
the appropriate C_API_VERSION and hash, add a new entry to cversions.txt.
If the API version was not changed, but the hash differs, you will need to
comment out the previous entry for that API version. For instance, in NumPy
1.9 annotations were added, which changed the hash, but the API was the
same as in 1.8. The hash serves as a check for API changes, but it is not
definitive.</p>
<p>If steps 1 and 2 are done correctly, compiling the release should not give
a warning “API mismatch detect at the beginning of the build”.</p>
</li>
<li><p>The numpy/core/include/numpy/numpyconfig.h will need a new
NPY_X_Y_API_VERSION macro, where X and Y are the major and minor version
numbers of the release. The value given to that macro only needs to be
increased from the previous version if some of the functions or macros in
the include files were deprecated.</p></li>
</ol>
<p>The C ABI version number in numpy/core/setup_common.py should only be
updated for a major release.</p>
</div>
<div class="section" id="check-the-release-notes">
<h4>Check the release notes<a class="headerlink" href="#check-the-release-notes" title="Permalink to this headline">¶</a></h4>
<p>Use <a class="reference external" href="https://github.com/hawkowl/towncrier">towncrier</a> to build the release note and
commit the changes. This will remove all the fragments from
<code class="docutils literal notranslate"><span class="pre">doc/release/upcoming_changes</span></code> and add <code class="docutils literal notranslate"><span class="pre">doc/release/&lt;version&gt;-note.rst</span></code>.
Note that currently towncrier must be installed from its master branch as the
last release (19.2.0) is outdated.</p>
<blockquote>
<div><p>towncrier –version “&lt;version&gt;”
git commit -m”Create release note”</p>
</div></blockquote>
<p>Check that the release notes are up-to-date.</p>
<p>Update the release notes with a Highlights section. Mention some of the
following:</p>
<blockquote>
<div><ul class="simple">
<li><p>major new features</p></li>
<li><p>deprecated and removed features</p></li>
<li><p>supported Python versions</p></li>
<li><p>for SciPy, supported NumPy version(s)</p></li>
<li><p>outlook for the near future</p></li>
</ul>
</div></blockquote>
</div>
<div class="section" id="update-the-release-status-and-create-a-release-tag">
<h4>Update the release status and create a release “tag”<a class="headerlink" href="#update-the-release-status-and-create-a-release-tag" title="Permalink to this headline">¶</a></h4>
<p>Identify the commit hash of the release, e.g. 1b2e1d63ff.</p>
<dl class="simple">
<dt>::</dt><dd><p>git co 1b2e1d63ff # gives warning about detached head</p>
</dd>
</dl>
<p>First, change/check the following variables in <code class="docutils literal notranslate"><span class="pre">pavement.py</span></code> depending on the
release version:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">RELEASE_NOTES</span> <span class="o">=</span> <span class="s1">&#39;doc/release/1.7.0-notes.rst&#39;</span>
<span class="n">LOG_START</span> <span class="o">=</span> <span class="s1">&#39;v1.6.0&#39;</span>
<span class="n">LOG_END</span> <span class="o">=</span> <span class="s1">&#39;maintenance/1.7.x&#39;</span>
</pre></div>
</div>
<p>Do any other changes. When you are ready to release, do the following
changes:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">diff</span> <span class="o">--</span><span class="n">git</span> <span class="n">a</span><span class="o">/</span><span class="n">setup</span><span class="o">.</span><span class="n">py</span> <span class="n">b</span><span class="o">/</span><span class="n">setup</span><span class="o">.</span><span class="n">py</span>
<span class="n">index</span> <span class="n">b1f53e3</span><span class="o">..</span><span class="mi">8</span><span class="n">b36dbe</span> <span class="mi">100755</span>
<span class="o">---</span> <span class="n">a</span><span class="o">/</span><span class="n">setup</span><span class="o">.</span><span class="n">py</span>
<span class="o">+++</span> <span class="n">b</span><span class="o">/</span><span class="n">setup</span><span class="o">.</span><span class="n">py</span>
<span class="o">@@</span> <span class="o">-</span><span class="mi">57</span><span class="p">,</span><span class="mi">7</span> <span class="o">+</span><span class="mi">57</span><span class="p">,</span><span class="mi">7</span> <span class="o">@@</span> <span class="n">PLATFORMS</span>           <span class="o">=</span> <span class="p">[</span><span class="s2">&quot;Windows&quot;</span><span class="p">,</span> <span class="s2">&quot;Linux&quot;</span><span class="p">,</span> <span class="s2">&quot;Solaris&quot;</span><span class="p">,</span> <span class="s2">&quot;Mac OS-</span>
 <span class="n">MAJOR</span>               <span class="o">=</span> <span class="mi">1</span>
 <span class="n">MINOR</span>               <span class="o">=</span> <span class="mi">7</span>
 <span class="n">MICRO</span>               <span class="o">=</span> <span class="mi">0</span>
<span class="o">-</span><span class="n">ISRELEASED</span>          <span class="o">=</span> <span class="kc">False</span>
<span class="o">+</span><span class="n">ISRELEASED</span>          <span class="o">=</span> <span class="kc">True</span>
 <span class="n">VERSION</span>             <span class="o">=</span> <span class="s1">&#39;</span><span class="si">%d</span><span class="s1">.</span><span class="si">%d</span><span class="s1">.</span><span class="si">%d</span><span class="s1">rc1&#39;</span> <span class="o">%</span> <span class="p">(</span><span class="n">MAJOR</span><span class="p">,</span> <span class="n">MINOR</span><span class="p">,</span> <span class="n">MICRO</span><span class="p">)</span>

 <span class="c1"># Return the git revision as a string</span>
</pre></div>
</div>
<p>And make sure the <code class="docutils literal notranslate"><span class="pre">VERSION</span></code> variable is set properly.</p>
<p>Now you can make the release commit and tag.  We recommend you don’t push
the commit or tag immediately, just in case you need to do more cleanup. We
prefer to defer the push of the tag until we’re confident this is the exact
form of the released code (see: <a class="reference internal" href="#push-tag-and-commit"><span class="std std-ref">Push the release tag and commit</span></a>):</p>
<blockquote>
<div><p>git commit -s -m “REL: Release.” setup.py
git tag -s &lt;version&gt;</p>
</div></blockquote>
<p>The <code class="docutils literal notranslate"><span class="pre">-s</span></code> flag makes a PGP (usually GPG) signed tag.  Please do sign the
release tags.</p>
<p>The release tag should have the release number in the annotation (tag
message).  Unfortunately, the name of a tag can be changed without breaking the
signature, the contents of the message cannot.</p>
<p>See: <a class="reference external" href="https://github.com/scipy/scipy/issues/4919">https://github.com/scipy/scipy/issues/4919</a> for a discussion of signing
release tags, and <a class="reference external" href="https://keyring.debian.org/creating-key.html">https://keyring.debian.org/creating-key.html</a> for instructions
on creating a GPG key if you do not have one.</p>
<p>To make your key more readily identifiable as you, consider sending your key
to public keyservers, with a command such as:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">gpg</span> <span class="o">--</span><span class="n">send</span><span class="o">-</span><span class="n">keys</span> <span class="o">&lt;</span><span class="n">yourkeyid</span><span class="o">&gt;</span>
</pre></div>
</div>
</div>
<div class="section" id="apply-patch-to-fix-bogus-strides">
<h4>Apply patch to fix bogus strides<a class="headerlink" href="#apply-patch-to-fix-bogus-strides" title="Permalink to this headline">¶</a></h4>
<p>NPY_RELAXED_STRIDE_CHECKING was made the default in NumPy 1.10.0 and bogus
strides are used in the development branch to smoke out problems. The
<a class="reference external" href="https://github.com/numpy/numpy/pull/5996">patch</a> should be updated if
necessary and applied to the release branch to rationalize the strides.</p>
</div>
<div class="section" id="update-the-version-of-the-master-branch">
<h4>Update the version of the master branch<a class="headerlink" href="#update-the-version-of-the-master-branch" title="Permalink to this headline">¶</a></h4>
<p>Increment the release number in setup.py. Release candidates should have “rc1”
(or “rc2”, “rcN”) appended to the X.Y.Z format.</p>
<p>Also create a new version hash in cversions.txt and a corresponding version
define NPY_x_y_API_VERSION in numpyconfig.h</p>
</div>
<div class="section" id="trigger-the-wheel-builds-on-travis-ci-and-appveyor">
<h4>Trigger the wheel builds on travis-ci and Appveyor<a class="headerlink" href="#trigger-the-wheel-builds-on-travis-ci-and-appveyor" title="Permalink to this headline">¶</a></h4>
<p>See the <em class="xref py py-obj">numpy wheels</em> repository.</p>
<p>In that repository edit the files:</p>
<ul class="simple">
<li><p><code class="docutils literal notranslate"><span class="pre">.travis.yml</span></code>;</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">appveyor.yml</span></code>.</p></li>
</ul>
<p>In both cases, set the <code class="docutils literal notranslate"><span class="pre">BUILD_COMMIT</span></code> variable to the current release tag -
e.g. <code class="docutils literal notranslate"><span class="pre">v1.11.1</span></code>.</p>
<p>Make sure that the release tag has been pushed.</p>
<p>Trigger a build by doing a commit of your edits to <code class="docutils literal notranslate"><span class="pre">.travis.yml</span></code> and
<code class="docutils literal notranslate"><span class="pre">appveyor.yml</span></code> to the repository:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">cd</span> <span class="o">/</span><span class="n">path</span><span class="o">/</span><span class="n">to</span><span class="o">/</span><span class="n">numpy</span><span class="o">-</span><span class="n">wheels</span>
<span class="c1"># Edit .travis.yml, appveyor.yml</span>
<span class="n">git</span> <span class="n">commit</span>
<span class="n">git</span> <span class="n">push</span>
</pre></div>
</div>
<p>The wheels, once built, appear at a Rackspace container pointed at by:</p>
<ul class="simple">
<li><p><a class="reference external" href="http://wheels.scipy.org">http://wheels.scipy.org</a></p></li>
<li><p><a class="reference external" href="https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com">https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com</a></p></li>
</ul>
<p>The HTTP address may update first, and you should wait 15 minutes after the
build finishes before fetching the binaries.</p>
</div>
<div class="section" id="make-the-release">
<h4>Make the release<a class="headerlink" href="#make-the-release" title="Permalink to this headline">¶</a></h4>
<p>Build the changelog and notes for upload with:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">paver</span> <span class="n">write_release</span>
</pre></div>
</div>
</div>
<div class="section" id="build-and-archive-documentation">
<h4>Build and archive documentation<a class="headerlink" href="#build-and-archive-documentation" title="Permalink to this headline">¶</a></h4>
<p>Do:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">cd</span> <span class="n">doc</span><span class="o">/</span>
<span class="n">make</span> <span class="n">dist</span>
</pre></div>
</div>
<p>to check that the documentation is in a buildable state. Then, after tagging,
create an archive of the documentation in the numpy/doc repo:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1"># This checks out github.com/numpy/doc and adds (``git add``) the</span>
<span class="c1"># documentation to the checked out repo.</span>
<span class="n">make</span> <span class="n">merge</span><span class="o">-</span><span class="n">doc</span>
<span class="c1"># Now edit the ``index.html`` file in the repo to reflect the new content,</span>
<span class="c1"># and commit the changes</span>
<span class="n">git</span> <span class="o">-</span><span class="n">C</span> <span class="n">dist</span><span class="o">/</span><span class="n">merge</span> <span class="n">commit</span> <span class="o">-</span><span class="n">a</span> <span class="s2">&quot;Add documentation for &lt;version&gt;&quot;</span>
<span class="c1"># Push to numpy/doc repo</span>
<span class="n">git</span> <span class="o">-</span><span class="n">C</span> <span class="n">push</span>
</pre></div>
</div>
</div>
<div class="section" id="update-pypi">
<h4>Update PyPI<a class="headerlink" href="#update-pypi" title="Permalink to this headline">¶</a></h4>
<p>The wheels and source should be uploaded to PyPI.</p>
<p>You should upload the wheels first, and the source formats last, to make sure
that pip users don’t accidentally get a source install when they were
expecting a binary wheel.</p>
<p>You can do this automatically using the <code class="docutils literal notranslate"><span class="pre">wheel-uploader</span></code> script from
<a class="reference external" href="https://github.com/MacPython/terryfy">https://github.com/MacPython/terryfy</a>.  Here is the recommended incantation for
downloading all the Windows, Manylinux, OSX wheels and uploading to PyPI.</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>NPY_WHLS=~/wheelhouse   # local directory to cache wheel downloads
CDN_URL=https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com
wheel-uploader -u $CDN_URL -w $NPY_WHLS -v -s -t win numpy 1.11.1rc1
wheel-uploader -u $CDN_URL -w warehouse -v -s -t macosx numpy 1.11.1rc1
wheel-uploader -u $CDN_URL -w warehouse -v -s -t manylinux1 numpy 1.11.1rc1
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">-v</span></code> flag gives verbose feedback, <code class="docutils literal notranslate"><span class="pre">-s</span></code> causes the script to sign the
wheels with your GPG key before upload. Don’t forget to upload the wheels
before the source tarball, so there is no period for which people switch from
an expected binary install to a source install from PyPI.</p>
<p>There are two ways to update the source release on PyPI, the first one is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ git clean -fxd  # to be safe
$ python setup.py sdist --formats=gztar,zip  # to check
# python setup.py sdist --formats=gztar,zip upload --sign
</pre></div>
</div>
<p>This will ask for your key PGP passphrase, in order to sign the built source
packages.</p>
<p>The second way is to upload the PKG_INFO file inside the sdist dir in the
web interface of PyPI. The source tarball can also be uploaded through this
interface.</p>
</div>
<div class="section" id="push-the-release-tag-and-commit">
<span id="push-tag-and-commit"></span><h4>Push the release tag and commit<a class="headerlink" href="#push-the-release-tag-and-commit" title="Permalink to this headline">¶</a></h4>
<p>Finally, now you are confident this tag correctly defines the source code that
you released you can push the tag and release commit up to github:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">git</span> <span class="n">push</span>  <span class="c1"># Push release commit</span>
<span class="n">git</span> <span class="n">push</span> <span class="n">upstream</span> <span class="o">&lt;</span><span class="n">version</span><span class="o">&gt;</span>  <span class="c1"># Push tag named &lt;version&gt;</span>
</pre></div>
</div>
<p>where <code class="docutils literal notranslate"><span class="pre">upstream</span></code> points to the main <a class="reference external" href="https://github.com/numpy/numpy.git">https://github.com/numpy/numpy.git</a>
repository.</p>
</div>
<div class="section" id="update-scipy-org">
<h4>Update scipy.org<a class="headerlink" href="#update-scipy-org" title="Permalink to this headline">¶</a></h4>
<p>A release announcement with a link to the download site should be placed in the
sidebar of the front page of scipy.org.</p>
<p>The scipy.org should be a PR at <a class="reference external" href="https://github.com/scipy/scipy.org">https://github.com/scipy/scipy.org</a>. The file
that needs modification is <code class="docutils literal notranslate"><span class="pre">www/index.rst</span></code>. Search for <code class="docutils literal notranslate"><span class="pre">News</span></code>.</p>
</div>
<div class="section" id="announce-to-the-lists">
<h4>Announce to the lists<a class="headerlink" href="#announce-to-the-lists" title="Permalink to this headline">¶</a></h4>
<p>The release should be announced on the mailing lists of
NumPy and SciPy, to python-announce, and possibly also those of
Matplotlib, IPython and/or Pygame.</p>
<p>During the beta/RC phase, an explicit request for testing the binaries with
several other libraries (SciPy/Matplotlib/Pygame) should be posted on the
mailing list.</p>
</div>
<div class="section" id="announce-to-linux-weekly-news">
<h4>Announce to Linux Weekly News<a class="headerlink" href="#announce-to-linux-weekly-news" title="Permalink to this headline">¶</a></h4>
<p>Email the editor of LWN to let them know of the release.  Directions at:
<a class="reference external" href="https://lwn.net/op/FAQ.lwn#contact">https://lwn.net/op/FAQ.lwn#contact</a></p>
</div>
<div class="section" id="after-the-final-release">
<h4>After the final release<a class="headerlink" href="#after-the-final-release" title="Permalink to this headline">¶</a></h4>
<p>After the final release is announced, a few administrative tasks are left to be
done:</p>
<blockquote>
<div><ul class="simple">
<li><p>Forward port changes in the release branch to release notes and release
scripts, if any, to master branch.</p></li>
<li><p>Update the Milestones in Trac.</p></li>
</ul>
</div></blockquote>
</div>
</div>
</div>
<div class="section" id="step-by-step-directions">
<h2>Step-by-Step Directions<a class="headerlink" href="#step-by-step-directions" title="Permalink to this headline">¶</a></h2>
<p>This file contains a walkthrough of the NumPy 1.14.5 release on Linux.
The commands can be copied into the command line, but be sure to
replace 1.14.5 by the correct version.</p>
<div class="section" id="release-walkthrough">
<h3>Release  Walkthrough<a class="headerlink" href="#release-walkthrough" title="Permalink to this headline">¶</a></h3>
<p>Note that in the code snippets below, <code class="docutils literal notranslate"><span class="pre">upstream</span></code> refers to the root repository on
github and <code class="docutils literal notranslate"><span class="pre">origin</span></code> to a fork in your personal account. You may need to make adjustments
if you have not forked the repository but simply cloned it locally. You can
also edit <code class="docutils literal notranslate"><span class="pre">.git/config</span></code> and add <code class="docutils literal notranslate"><span class="pre">upstream</span></code> if it isn’t already present.</p>
<div class="section" id="backport-pull-requests">
<h4>Backport Pull Requests<a class="headerlink" href="#backport-pull-requests" title="Permalink to this headline">¶</a></h4>
<p>Changes that have been marked for this release must be backported to the
maintenance/1.14.x branch.</p>
</div>
<div class="section" id="update-release-documentation">
<h4>Update Release documentation<a class="headerlink" href="#update-release-documentation" title="Permalink to this headline">¶</a></h4>
<p>The file <code class="docutils literal notranslate"><span class="pre">doc/changelog/1.14.5-changelog.rst</span></code> should be updated to reflect
the final list of changes and contributors. This text can be generated by:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ python tools/changelog.py $GITHUB v1.14.4..maintenance/1.14.x &gt; doc/changelog/1.14.5-changelog.rst
</pre></div>
</div>
<p>where <code class="docutils literal notranslate"><span class="pre">GITHUB</span></code> contains your github access token. This text may also be
appended to <code class="docutils literal notranslate"><span class="pre">doc/release/1.14.5-notes.rst</span></code> for release updates, though not
for new releases like <code class="docutils literal notranslate"><span class="pre">1.14.0</span></code>, as the changelogs for <code class="docutils literal notranslate"><span class="pre">*.0</span></code> releases tend to be
excessively long. The <code class="docutils literal notranslate"><span class="pre">doc/source/release.rst</span></code> file should also be
updated with a link to the new release notes. These changes should be committed
to the maintenance branch, and later will be forward ported to master.</p>
</div>
<div class="section" id="finish-the-release-note">
<h4>Finish the Release Note<a class="headerlink" href="#finish-the-release-note" title="Permalink to this headline">¶</a></h4>
<p>Fill out the release note <code class="docutils literal notranslate"><span class="pre">doc/release/1.14.5-notes.rst</span></code> calling out
significant changes.</p>
</div>
<div class="section" id="prepare-the-release-commit">
<h4>Prepare the release commit<a class="headerlink" href="#prepare-the-release-commit" title="Permalink to this headline">¶</a></h4>
<p>Checkout the branch for the release, make sure it is up to date, and clean the
repository:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ git checkout maintenance/1.14.x
$ git pull upstream maintenance/1.14.x
$ git submodule update
$ git clean -xdfq
</pre></div>
</div>
<p>Edit pavement.py and setup.py as detailed in HOWTO_RELEASE:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ gvim pavement.py setup.py
$ git commit -a -m&quot;REL: NumPy 1.14.5 release.&quot;
</pre></div>
</div>
<p>Sanity check:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ python runtests.py -m &quot;full&quot;  # NumPy &lt; 1.17 only
$ python3 runtests.py -m &quot;full&quot;
</pre></div>
</div>
<p>Push this release directly onto the end of the maintenance branch. This
requires write permission to the numpy repository:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ git push upstream maintenance/1.14.x
</pre></div>
</div>
<p>As an example, see the 1.14.3 REL commit: <a class="reference external" href="https://github.com/numpy/numpy/commit/73299826729be58cec179b52c656adfcaefada93">https://github.com/numpy/numpy/commit/73299826729be58cec179b52c656adfcaefada93</a>.</p>
</div>
<div class="section" id="build-source-releases">
<h4>Build source releases<a class="headerlink" href="#build-source-releases" title="Permalink to this headline">¶</a></h4>
<p>Paver is used to build the source releases. It will create the <code class="docutils literal notranslate"><span class="pre">release</span></code> and
<code class="docutils literal notranslate"><span class="pre">release/installers</span></code> directories and put the <code class="docutils literal notranslate"><span class="pre">*.zip</span></code> and <code class="docutils literal notranslate"><span class="pre">*.tar.gz</span></code>
source releases in the latter.</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ python3 -m cython --version  # check for correct cython version
$ paver sdist  # sdist will do a git clean -xdf, so we omit that
</pre></div>
</div>
</div>
<div class="section" id="build-wheels">
<h4>Build wheels<a class="headerlink" href="#build-wheels" title="Permalink to this headline">¶</a></h4>
<p>Trigger the wheels build by pointing the numpy-wheels repository at this
commit. This can take a while. The numpy-wheels repository is cloned from
<a class="reference external" href="https://github.com/MacPython/numpy-wheels">https://github.com/MacPython/numpy-wheels</a>. Start with a pull as the repo
may have been accessed and changed by someone else and a push will fail:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ cd ../numpy-wheels
$ git pull upstream master
$ git branch &lt;new version&gt;  # only when starting new numpy version
$ git checkout v1.14.x  # v1.14.x already existed for the 1.14.4 release
</pre></div>
</div>
<p>Edit the <code class="docutils literal notranslate"><span class="pre">.travis.yml</span></code> and <code class="docutils literal notranslate"><span class="pre">.appveyor.yml</span></code> files to make sure they have the
correct version, and put in the commit hash for the <code class="docutils literal notranslate"><span class="pre">REL</span></code> commit created
above for <code class="docutils literal notranslate"><span class="pre">BUILD_COMMIT</span></code>, see the _example from <em class="xref py py-obj">v1.14.3</em>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ gvim .travis.yml .appveyor.yml
$ git commit -a
$ git push upstream HEAD
</pre></div>
</div>
<p>Now wait. If you get nervous at the amount of time taken – the builds can take
several hours– you can check the build progress by following the links
provided at <a class="reference external" href="https://github.com/MacPython/numpy-wheels">https://github.com/MacPython/numpy-wheels</a> to check the travis
and appveyor build status. Check if all the needed wheels have been built and
uploaded before proceeding. There should currently be 22 of them at
<a class="reference external" href="https://wheels.scipy.org">https://wheels.scipy.org</a>, 4 for Mac, 8 for Windows, and 10 for Linux.
Note that sometimes builds, like tests, fail for unrelated reasons and you will
need to restart them.</p>
</div>
<div class="section" id="download-wheels">
<h4>Download wheels<a class="headerlink" href="#download-wheels" title="Permalink to this headline">¶</a></h4>
<p>When the wheels have all been successfully built, download them using the <code class="docutils literal notranslate"><span class="pre">wheel-uploader</span></code>
in the <code class="docutils literal notranslate"><span class="pre">terryfy</span></code> repository.  The terryfy repository may be cloned from
<a class="reference external" href="https://github.com/MacPython/terryfy">https://github.com/MacPython/terryfy</a> if you don’t already have it.  The
wheels can also be uploaded using the <code class="docutils literal notranslate"><span class="pre">wheel-uploader</span></code>, but we prefer to
download all the wheels to the <code class="docutils literal notranslate"><span class="pre">../numpy/release/installers</span></code> directory and
upload later using <code class="docutils literal notranslate"><span class="pre">twine</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ cd ../terryfy
$ git pull upstream master
$ CDN_URL=https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com
$ NPY_WHLS=../numpy/release/installers
$ ./wheel-uploader -u $CDN_URL -n -v -w $NPY_WHLS -t win numpy 1.14.5
$ ./wheel-uploader -u $CDN_URL -n -v -w $NPY_WHLS -t manylinux1 numpy 1.14.5
$ ./wheel-uploader -u $CDN_URL -n -v -w $NPY_WHLS -t macosx numpy 1.14.5
</pre></div>
</div>
<p>If you do this often, consider making CDN_URL and NPY_WHLS part of your default
environment.</p>
</div>
<div class="section" id="generate-the-readme-files">
<h4>Generate the README files<a class="headerlink" href="#generate-the-readme-files" title="Permalink to this headline">¶</a></h4>
<p>This needs to be done after all installers are downloaded, but before the pavement
file is updated for continued development:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ cd ../numpy
$ paver write_release
</pre></div>
</div>
</div>
<div class="section" id="tag-the-release">
<h4>Tag the release<a class="headerlink" href="#tag-the-release" title="Permalink to this headline">¶</a></h4>
<p>Once the wheels have been built and downloaded without errors, go back to your
numpy repository in the maintenance branch and tag the <code class="docutils literal notranslate"><span class="pre">REL</span></code> commit, signing
it with your gpg key:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ git tag -s v1.14.5
</pre></div>
</div>
<p>You should upload your public gpg key to github, so that the tag will appear
“verified” there.</p>
<p>Check that the files in <code class="docutils literal notranslate"><span class="pre">release/installers</span></code> have the correct versions, then
push the tag upstream:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ git push upstream v1.14.5
</pre></div>
</div>
<p>We wait until this point to push the tag because it is public and should not
be changed after it has been pushed.</p>
</div>
<div class="section" id="reset-the-maintenance-branch-into-a-development-state">
<h4>Reset the maintenance branch into a development state<a class="headerlink" href="#reset-the-maintenance-branch-into-a-development-state" title="Permalink to this headline">¶</a></h4>
<p>Add another <code class="docutils literal notranslate"><span class="pre">REL</span></code> commit to the numpy maintenance branch, which resets the
<code class="docutils literal notranslate"><span class="pre">ISREALEASED</span></code> flag to <code class="docutils literal notranslate"><span class="pre">False</span></code> and increments the version counter:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ gvim pavement.py setup.py
</pre></div>
</div>
<p>Create release notes for next release and edit them to set the version:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ cp doc/release/template.rst doc/release/1.14.6-notes.rst
$ gvim doc/release/1.14.6-notes.rst
$ git add doc/release/1.14.6-notes.rst
</pre></div>
</div>
<p>Add new release notes to the documentation release list:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ gvim doc/source/release.rst
</pre></div>
</div>
<p>Commit the result:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ git commit -a -m&quot;REL: prepare 1.14.x for further development&quot;
$ git push upstream maintenance/1.14.x
</pre></div>
</div>
</div>
<div class="section" id="upload-to-pypi">
<h4>Upload to PyPI<a class="headerlink" href="#upload-to-pypi" title="Permalink to this headline">¶</a></h4>
<p>Upload to PyPI using <code class="docutils literal notranslate"><span class="pre">twine</span></code>. A recent version of <code class="docutils literal notranslate"><span class="pre">twine</span></code> of is needed
after recent PyPI changes, version <code class="docutils literal notranslate"><span class="pre">1.11.0</span></code> was used here.</p>
<div class="highlight-sh notranslate"><div class="highlight"><pre><span></span>$ <span class="nb">cd</span> ../numpy
$ twine upload release/installers/*.whl
$ twine upload release/installers/numpy-1.14.5.zip  <span class="c1"># Upload last.</span>
</pre></div>
</div>
<p>If one of the commands breaks in the middle, which is not uncommon, you may
need to selectively upload the remaining files because PyPI does not allow the
same file to be uploaded twice. The source file should be uploaded last to
avoid synchronization problems if pip users access the files while this is in
process. Note that PyPI only allows a single source distribution, here we have
chosen the zip archive.</p>
</div>
<div class="section" id="upload-files-to-github">
<h4>Upload files to github<a class="headerlink" href="#upload-files-to-github" title="Permalink to this headline">¶</a></h4>
<p>Go to <a class="reference external" href="https://github.com/numpy/numpy/releases">https://github.com/numpy/numpy/releases</a>, there should be a <code class="docutils literal notranslate"><span class="pre">v1.14.5</span>
<span class="pre">tag</span></code>, click on it and hit the edit button for that tag. There are two ways to
add files, using an editable text window and as binary uploads.</p>
<ul class="simple">
<li><p>Cut and paste the <code class="docutils literal notranslate"><span class="pre">release/README.md</span></code> file contents into the text window.</p></li>
<li><p>Upload <code class="docutils literal notranslate"><span class="pre">release/installers/numpy-1.14.5.tar.gz</span></code> as a binary file.</p></li>
<li><p>Upload <code class="docutils literal notranslate"><span class="pre">release/installers/numpy-1.14.5.zip</span></code> as a binary file.</p></li>
<li><p>Upload <code class="docutils literal notranslate"><span class="pre">release/README.rst</span></code> as a binary file.</p></li>
<li><p>Upload <code class="docutils literal notranslate"><span class="pre">doc/changelog/1.14.5-changelog.rst</span></code> as a binary file.</p></li>
<li><p>Check the pre-release button if this is a pre-releases.</p></li>
<li><p>Hit the <code class="docutils literal notranslate"><span class="pre">{Publish,Update}</span> <span class="pre">release</span></code> button at the bottom.</p></li>
</ul>
</div>
<div class="section" id="upload-documents-to-numpy-org">
<h4>Upload documents to numpy.org<a class="headerlink" href="#upload-documents-to-numpy-org" title="Permalink to this headline">¶</a></h4>
<p>This step is only needed for final releases and can be skipped for
pre-releases. <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">merge-doc</span></code> clones the <code class="docutils literal notranslate"><span class="pre">numpy/doc</span></code> repo into
<code class="docutils literal notranslate"><span class="pre">doc/build/merge</span></code> and updates it with the new documentation:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ pushd doc
$ make dist
$ make merge-doc
$ popd
</pre></div>
</div>
<p>If the release series is a new one, you will need to add a new section to the
<code class="docutils literal notranslate"><span class="pre">doc/build/merge/index.html</span></code> front page just after the “insert here” comment:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ gvim doc/build/merge/index.html +/&#39;insert here&#39;
</pre></div>
</div>
<p>Otherwise, only the <code class="docutils literal notranslate"><span class="pre">zip</span></code> and <code class="docutils literal notranslate"><span class="pre">pdf</span></code> links should be updated with the
new tag name:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ gvim doc/build/merge/index.html +/&#39;tag v1.14&#39;
</pre></div>
</div>
<p>You can “test run” the new documentation in a browser to make sure the links
work:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ firefox doc/build/merge/index.html
</pre></div>
</div>
<p>Once everything seems satisfactory, commit and upload the changes:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ pushd doc/build/merge
$ git commit -am&quot;Add documentation for v1.14.5&quot;
$ git push
$ popd
</pre></div>
</div>
</div>
<div class="section" id="announce-the-release-on-scipy-org">
<h4>Announce the release on scipy.org<a class="headerlink" href="#announce-the-release-on-scipy-org" title="Permalink to this headline">¶</a></h4>
<p>This assumes that you have forked <a class="reference external" href="https://github.com/scipy/scipy.org">https://github.com/scipy/scipy.org</a>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ cd ../scipy.org
$ git checkout master
$ git pull upstream master
$ git checkout -b numpy-1.14.5
$ gvim www/index.rst # edit the News section
$ git commit -a
$ git push origin HEAD
</pre></div>
</div>
<p>Now go to your fork and make a pull request for the branch.</p>
</div>
<div class="section" id="announce-to-mailing-lists">
<h4>Announce to mailing lists<a class="headerlink" href="#announce-to-mailing-lists" title="Permalink to this headline">¶</a></h4>
<p>The release should be announced on the numpy-discussion, scipy-devel,
scipy-user, and python-announce-list mailing lists. Look at previous
announcements for the basic template. The contributor and PR lists are the same
as generated for the release notes above. If you crosspost, make sure that
python-announce-list is BCC so that replies will not be sent to that list.</p>
</div>
<div class="section" id="post-release-tasks">
<h4>Post-Release Tasks<a class="headerlink" href="#post-release-tasks" title="Permalink to this headline">¶</a></h4>
<p>Forward port the documentation changes <code class="docutils literal notranslate"><span class="pre">doc/release/1.14.5-notes.rst</span></code>,
<code class="docutils literal notranslate"><span class="pre">doc/changelog/1.14.5-changelog.rst</span></code> and add the release note to
<code class="docutils literal notranslate"><span class="pre">doc/source/release.rst</span></code>.</p>
</div>
</div>
</div>
</div>


          </div>
        </div>
          </div>
        </div>
      </div>
    </div>

    <div class="container container-navbar-bottom">
      <div class="spc-navbar">
        
      </div>
    </div>
    <div class="container">
    <div class="footer">
    <div class="row-fluid">
    <ul class="inline pull-left">
      <li>
        &copy; Copyright 2008-2019, The SciPy community.
      </li>
      <li>
      Last updated on Feb 20, 2020.
      </li>
      <li>
      Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 2.4.2.
      </li>
    </ul>
    </div>
    </div>
    </div>
  </body>
</html>